Communications security systems

ABSTRACT

A method of establishing secure communications between a first computer, eg a client computer, and a second computer, eg a web server, whereby the client computer receives one or more security policies relating to the web server. A client application examines the client computer and preferably configures one or more aspects of the client computer in order to make it comply with the security policies. Once the web server receives the results of this examination and/or configuration process, it can determine whether the secure communications are to be established and whether any restrictions need to be placed on this communication and/or the activity conducted via the communication.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/533,278, filed on Jun. 26, 2012, which is a continuation of U.S.patent application Ser. No. 12/303,094, filed Mar. 26, 2012, which is anational stage application under 35 USC §371(c) of PCT Application No.PCT/AU2007/000747, entitled “COMMUNICATIONS SECURITY SYSTEM,” filed May29, 2007, which claims priority from Australian Patent Application No.2006902878, filed May 29, 2006 and Australian Patent Application No.2006905620, filed Oct. 10, 2006 all of which are hereby incorporated byreference herein.

FIELD OF THE INVENTION

This invention relates generally to the field of establishing andmaintaining secure connections over a network such as the Internet.

BACKGROUND OF THE INVENTION

The Internet enables people across the globe to buy and sell, andinteract as never before. Internet activities however, whether involvingemail, personal information such as credit card details, visiting ane-commerce based website or logging into an online banking system,require effective security and encryption mechanisms to ensure personaldata and sensitive information are safe from misappropriation and onlinefraud. Threats to this security include fraudulent attacks from thirdparties or programs such as computer viruses, worms, trojan horses andspyware which usually install themselves on a user's computer throughdeception, and are typically capable of accessing and compromisingimportant data, affecting the performance of the computer and/ormonitoring the activities of users.

One means of minimising the chances of damage caused by such threats isto completely isolate the computer from other computers and networksfrom which such threats may be received. Although this approach maysignificantly reduce the susceptibility of the computer to an attack orthe chances of the computer becoming infected, such an action is clearlyimpractical for many users as they are severely restricted in theiractivities.

An alternative approach to dealing with such threats is to install asecurity firewall and/or antivirus software, which typically run in thebackground of an operating system, detecting and ideally removing anysuspicious processes or software. While such security programs arecapable of protecting a computer from the large proportion of threats, acomputer will only continue to be protected from such threats if theseprograms are constantly updated to deal with new viruses and worms beingdeveloped everyday. Therefore, if a computer is not protected byeffective security programs or these programs are not regularly updated,the computer is potentially left open to attacks from viruses or worms.As the abovementioned threats are typically passed from computer tocomputer, a compromised computer is not only an issue for its own users,but also users of other computers on the network, such as the Internet,to which the compromised computer may connect.

Another problem with conventional security programs and systems is thatthe user is left alone in his responsibility to keep the computer safeand infection free. Therefore, a user neglecting to properly protectagainst relevant threats may have his or her Internet activity monitoredand personal information misappropriated. In situations where sensitiveinformation such as bank or credit details are being transmitted,misappropriation of this information could lead to the fraudulentappropriation of funds from the user's financial accounts.

While early attempts at password protection have slowly evolved to moresophisticated systems, virtually all current password protectionsecurity systems on the Internet do not guard against fraudulent attackssuch as phishing. One example of phishing is where an email is received,supposedly from the bank or institution a user deals with, whichrequests urgent verification of a user's details to avoid their accountbeing suspended. Clicking on a link within the email typically forwardsthe user to a mock site which is made to look like the official site ofthe bank or institution the user is accustomed to and invites the userto enter their login and password. Once these details are in thepossession of third parties, they may use the information to gain accessto the user's financial accounts or other sensitive information.

These types of online fraud attacks undermine customer confidence andloyalty in an online service provider, the brand value of the bank orother institution, and the trust relationship as a whole in relation toactivities and transactions conducted over the Internet.

The firewall and antivirus security programs discussed above areprimarily directed at protecting user's from malicious attacks orprograms on the computer or network system, rather than from phishingattacks where the dissemination of a user's information occurs via awebsite to which the user is misdirected by deception. Securityapplications that do deal with phishing attacks only manage to secureusers from known phishing sites by adopting a black list approach.However, new phishing sites and malicious applications are identifiedeveryday and until these threats are verified and placed on a blacklist, a user's computer is left vulnerable.

Accordingly, it is an object of the present invention to provide a meansof securing communications across a network from security threats thatmay be present on the user's computer, or that may be transmitted from acompromised computer within a network.

It is a further object of the present invention to provide a means ofprotecting against security threats or websites to which the user isfraudulently directed.

Any discussion of documents, devices, acts or knowledge in thisspecification is included to explain the context of the invention. Itshould not be taken as an admission that any of the material formed partof the prior art base or the common general knowledge in the relevantart on or before the priority date of the claim herein.

SUMMARY OF THE INVENTION

Broadly, the invention allows secure communications to be establishedbetween two computers by ensuring that at least one of the communicatingcomputers is aware of the configuration of the other before adetermination is made that secure communications is allowed to beestablished. In this way, the decision of whether or not to establishsecure communications is made with knowledge of whether there exist anythreats and/or potential threats that may be affect the security of thecommunications. If the decision is made to establish securecommunications, restrictions may be placed on the activity that can beconducted over the secure connections once established.

In one aspect, the present invention provides a method of establishingsecure communications between a first computer and a second computer,the method including the steps of:

a) communicating to the first computer at least one security policyrelating to the second computer;

b) initiating an examination process on the first computer in order toevaluate whether the first computer complies with the security policy;

c) the first computer communicating the results of the examinationprocess to the second computer; and

d) determining at least one aspect of the secure communications betweenthe first computer and the second computer;

wherein the determination of at least one aspect of the securecommunications between the first computer and second computer is basedat least in part on the results of the examination process.

In another aspect, the present invention provides a computer program forestablishing secure communications between a first computer and a secondcomputer, said computer program including computer instruction code forexecuting tasks including:

a) communicating to the first computer at least one security policyrelating to the second computer;

b) initiating an examination process on the first computer in order toevaluate whether the first computer complies with the security policy;

c) receiving the results of the examination process; and

d) determining at least one aspect of the secure communications betweenthe first computer and the second computer;

wherein the determination of at least one aspect of the securecommunications between the first computer and second computer is basedat least in part on the results of the examination process.

In yet another aspect, the present invention provides a computerprogrammed in accordance with the above method.

In yet another aspect, the present invention provides a computer systemincluding a first computer and a second computer, each of the firstcomputer and the second computer respectively programmed in accordancewith the above method.

In one form, at least one of the computers may also be configured inaccordance with certain requirements set out in a security policy so asto minimise any threats or potential threats that may affect thesecurity of the communications.

It will be appreciated that the invention can be implemented in a mannerwhere each communicating computer is both a first and second computer,thereby allowing each computer to be aware of the configuration of theother or ensure that the other meets certain requirements before securecommunications are established.

The term computer is intended to be construed broadly and encompass anyelectronic device that stores, retrieves, and processes data, and can beprogrammed with instructions, including personal desktop computers,laptops and notebooks, handheld personal digital assistants (PDAs),workstations, servers, mainframes, etc. Accordingly, in one form, theinvention may be implemented where one or both of these computers areservers.

The term list is intended to be construed broadly and include ordered orunordered listing of items, tables, databases and records, etc.

There has thus been outlined, rather broadly, the more importantfeatures of the invention in order that the detailed description of anembodiment thereof may be better understood, and in order that thepresent contribution to the art may be better appreciated.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention will be described withreference to the accompanying drawing, in which:

FIG. 1 is a schematic illustration in overview of the components of animplementation of the invention;

FIG. 2 is a screenshot of one form of the policy generator applicationof the implementation in FIG. 1;

FIG. 3 is context diagram illustrating the handshake process betweenclient application and the server in the implementation in FIG. 1; and

FIG. 4 is a flowchart illustrating the handshake process in FIG. 3.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention is not specific to any particular hardware orsoftware implementation, and is at a conceptual level above specifics ofimplementation. It is to be understood that various other embodimentsand variations of the invention may be produced without departing fromthe spirit or scope of the invention. The following is provided toassist in understanding the practical implementation of particularembodiments of the invention.

FIG. 1 shows a security system 200, which includes a client application10 installed on a client computer 20 which is used by a user to conductonline activity over a network 30 such as the Internet involving asystem server 50. The client application 10 regulates security aspectsof the client computer 20 during a transaction that is about to happenwith a server and the activities undertaken by user 40 when using theclient computer 20. The client application 10 may also communicate withthe system server 50 to secure a particular activity, by accessing thepolicy database 60, the community database 61 and/or the programdatabase 62, each of which contain information relevant to the securityof the client computer 20.

Whilst the present implementation is described in relation to theInternet, it will be appreciated that the present invention may beapplied to any networked or other communications arrangement, withappropriate modifications.

It will also be appreciated that while the policy database 60, thecommunity database 61 and the program database 62 have been described asthree distinct databases, each of these databases may be a differentaspect of a single central or distributed database. Also, it ispreferable that at least some of the data stored in these databases ismirrored locally on the client computer 20 for ease of reference.

The system 200 protects the user 40 against attacks such as phishing byallowing the client application 10 and/or the user 40 to identify, forexample, the web server 70 to which they are trying to connect, anddetermine whether or not the web server 70 is authentic. If it is foundthat the web server 70 is not authentic, for example it may have beensetup in an attempt at phishing, the connection is refused and the user40 is informed. If the web server is found to be authentic, the clientapplication 10 facilitates the connection to the web server 70 to carryout the required activities. During the connection process, and once aconnection is established, all out-going data submissions are supervisedby the client application 10. Furthermore, if the web server 70 belongsto a web service provider 80, such as an online bank which is asubscriber to system 200, the web server 70 may require that clientapplication 10 initiate a configuration process on the client computer20 to ensure that this computer adheres to certain security policies 85and/or is secured in lockdown mode. These restrictions will minimise thechances of the activities being compromised or the transmitted databeing misappropriated by third parties. In order to determine whichconnections are to be allowed and which are not, and to determine whichsecurity policies 85 apply or which applications 90 are able to runduring lockdown mode, reference is made to the policy database 60, thecommunity database 61 and the program database 62. Alternatively, webserver 70 may simply require an examination of client computer 20 beconducted and that information relating to the configuration of clientcomputer 20 be communicated to web server 70 so that it can determinewhether the communications should proceed. Further details in relationto each of these aspects of the system 200 are included below.

It will be appreciated, however, that while the below embodiments arediscussed in the context of communications between a client computer 20and a web server 70, other embodiments of the invention may beapplicable in regulating the security of communications between two ormore client computers, whereby in one form, the security policies 85 ofthese computers are uploaded to the policy database 60 or exchangedduring the handshake process, or in another form, where the securitypolicies are exchanged directly between the client computers during thehandshake process.

Identification

One aspect of the system 200 is identifying a server such as the webserver 70 with web fingerprinting. During this process, a unique webfingerprint 100 is generated by the client application 10 for eachcommunication request in order to identify the authenticity of the webserver 70 or other server, (eg a bank website allowing financialtransactions). For HTTP requests, or more generally, for non-SSLrequests, the SHA-1 fingerprint 100 of the requested URL (without theHTTP parameters) is used to identify the web server 70. SHA-1 is acryptographic hash function belonging to the SHA (Secure Hash Algorithm)family. For SST requests, it will be appreciated that fingerprint 100 ofthe certificate is used in addition to the above fingerprintcalculation. It will be appreciated that this is a high securityattribute which is not forgeable. Of course, alternative hashingalgorithms or other fingerprint generating approaches could be used.

In operation, the web server 70 will present a digital certificateduring the SSL-handshake and based on the SHA-1 (or similar hashingfunctions like SHA-256) fingerprint 100, the web server 70 can beidentified. It will be appreciated that the SST certificatefingerprinting is not the only way to identify a web server 70 and thatthere could be other attributes used in the authentication process likethe IP address, URL or other suitable protocol.

The identification of the web server 70 is displayed to user 40,preferably using a non-forgeable browser-independent window 110. For alloutgoing data submissions, the system calculates the web fingerprint 100for each web request and checks the authenticity of the web server 70 bycomparing this unique fingerprint 100 to those already stored in thecommunity database 61. The community database 61 contains webfingerprints which have already been authenticated by user 40 or otherusers of the system 200. If the web fingerprint 100 matches one of thesealready authenticated web fingerprints, the web server 70 isauthenticated and the connection is allowed to proceed.

If the web fingerprint 100 does not match one of these alreadyauthenticated web fingerprints, the client application 10 prompts user40 to confirm whether the connection to web server 70 should be allowedto proceed and whether web server 70 should be identified as beingauthentic. In order to assist user 40 is making this decision, clientapplication 10 may display details such as the IP address, serverlocation, etc of web server 70 in the browser-independent window 110.Furthermore, once the user 40 has indicated that the web server 70 isauthentic, the client application 10 will relay this information to thesystem server 50 which will then create an entry in the communitydatabase 61 for reference by other users attempting to connect to webserver 70. Preferably, this information is also stored locally by theclient application 10 so that when the user 40 attempts to connect tothe web server 70 at a later time, the web fingerprint 100 is simplycompared to the local data maintained by the client application 10 andsubsequently authenticated.

The operation of this method of identification is further describedusing the following example. An online business such as an online bankprovides the client application 10 with details of a web server 70, suchas hostnames/URLs, SSL certificate fingerprints and/or IPaddresses/ranges. Based on this information, the client applicationgenerates a unique web fingerprint 100 which, once authenticated andstored by the client application 10, can be used in future transactionsalong with a typical login and password system to identify the webserver 70 and establish a secure connection.

In one embodiment, the client application 10 may also generate a uniqueweb fingerprint 100 for the client computer 20 which is then transmittedto the web server 70 in order to identify the client computer 20 to theweb server 70.

In circumstances where the web server 70 is owned by a web serviceprovider 80, who is a subscriber to system 200, the client applicationmay alternatively identify web server 70 by reference to the policydatabase 60 without the need to compare fingerprints.

Guaranteed Authentication Program (GAP)

The Guaranteed Authentication Program (GAP) mode is part of the system200 where once the web service provider 80 has been identified as asubscriber of the system 200, it allows security policies 85 to beapplied to the client computer 20 and in some cases, the secure lockdownof the client computer 20 as described later.

As the client application 10 supervises all outgoing connections, itwill automatically enable the GAP mode if it detects a connectionbetween a client computer 20 having the client application and a webservice provider 80 who is a subscriber of the system 200, ie a GAPparticipant. Once activated, the client application 10 shows anon-forgeable browser-independent window 110 with the image and name ofthe connected web service provider 80. The GAP mode also incorporatesthe IP address and SST certificate fingerprints 100 and it is thereforenot vulnerable to any DNS spoofing, man-in-the-middle or other pharmingattacks, ie hacker's attack aiming to redirect a website's traffic toanother (bogus) website.

The web service provider 80 (eg bank) uses a policy generatorapplication 120, which may be an application installed on the webservice provider's internal systems or a web applet installed on thesystem server 50, or any other suitable location, to generate an XMLfile 130 consisting of information such as allowed URL's, certificatefingerprints 100, IP addresses, name, description, bitmap and thehashing-server URLs, as well as the hashing server SSL fingerprints andrelevant security policies 85. The XML file 130 is signed using aSHA-256 (which is another cryptographic hash function of the Secure HashAlgorithm family) hash value and then incorporated into the policydatabase 60 and accessed by the users of the system 200 as required.

For increased security, the hash value of XML file 130 may additionallybe sent to a separate Internet update server, such as the GAP hashserver (not shown), which is preferably hosted in a secure environmentwith government certification. Alternatively, where the web serviceprovider 80 chooses to use its own or a third party hashing server 150,the SHA-256 hash is available via MIPS.

In this case, during initialization of the GAP mode, the clientapplication 10 calculates the hash of the XML file 130 and compares thishash to the value it retrieves either from the secure GAP server (thisis done on top of the consistency check of the local settings, whichprevents that any settings can be altered by an unknown source likespyware or virus), or from the hashing server 150 specified in the XMLfile 130.

The Secure Lockdown

Once the GAP mode described in the previous section is enabled, theclient application 10 may configure the client computer 20 in accordancewith the security policies 85 pre-defined by the web service provider80, which may involve the initiation of the “lock down” process. It isto be understood that the “lock down” may be insisted on by the webservice provider 80 so that it can pro-actively make sure that only“safe” computers, ie those that comply with the security policies 85 aregranted access to their systems to conduct online activity.

In an alternative embodiment, the client application 10 may examine theclient computer 20 and simply notify the user 40 and/or the web serviceprovider 80 that the client computer 20 does not comply with thesecurity policies 85 but not at that point configure the client computer20 or restrict the online activities of the user 40.

If the lock down mode is enabled by the security policies 85, the clientapplication 10 will automatically check all processes running on theclient computer 20. A web service provider 80 can therefore make surethe client computer 20 is safe before any activity takes place.

In secure lock down mode, the client application refers to the programdatabase 62 which stores information relating to known and commonprocesses, and is continually updated by the administrators of thesystem 200. If an unknown process is detected by the client application10, the user 40 and/or web server 70 are warned that there is an unknownprocess running on the client computer 20. To make sure that only knownand “good” software is running, all unknown processes are marked aspotentially malicious and the user 40 is then given the choice to closethe corresponding programs 90, to let the client application 10 try toclose programs 90 by terminating relevant processes or to proceedwithout closing the programs 90. However, the result of this decision issubmitted to the web service provider 80 and based on the preconfiguredsecurity policies 85 of the web server 70, the user 40 may not be ableto proceed with the connection if the security policy 85 has not beencomplied with. One example of such a situation is if malicious programs90 or processes are running on the client computer 20 and cannot bestopped by client application 10. Alternatively, the user 40 may beallowed to proceed only with certain activities or may have restrictionsplaced these activities. One example of this is where user 40 isrestricted from conducting banking transactions for amounts greater than$1000.

Security Policies

Some examples of the different types of security policies 85 aredetailed below:

Access Control

The Access control policies indicate which users are allowed to requestand access an online service. The process of identification as discussedabove my also form part of these policies.

Trust Policies

The trust policies define exactly which components have to be trusted inorder to complete the online activity. These can include Hostnames, SSLCertificates, but can also be applied to the other sections and caninclude the identity or Internet access policies like Geo-IP.

System Policies

The system policies regulate user activity based on the overallconnection topology and can apply different restrictions, for example,if user 40 has VPN access to web server 70.

Network Policies

The network policies define who/when/what user/software is allowed torequest either the Internet or a specific service. This policy caninclude, for example, a sophisticated personal firewall blockingInternet requests to non-related sites only during an online activity.

The GAP participants can define the security policies 85 using thepolicy generator application 120 as discussed above. A screenshot of oneform of the policy generator application 120 is illustrated at FIG. 2.

The behaviour of the client application 10 in relation to a particularweb server 70 and/or web service provider 80, and all the correspondingoptions relating to the policy database 60, the lockdown mode and otheraspects and components can be configured with the security policies 85configuration processes provided by the policy generator application120.

An example of a workflow for the secure generation and storage ofsecurity policies is as follows:

The security policy 85 is defined by the web service provider 80 usingpolicy generator application 120,

The security policy 85 is saved to the XML file 130 (eg customer.xml),

The hash value of XML file 130 is generated and noted by the web serviceprovider 80,

The XML tile 130 is securely uploaded to system server 50,

An email with the hash value and unique ID generated on the systemserver 50 is forwarded to the web service provider 80,

If the web service provider's 80 noted hash value matches the hash valuein the email, the security policy 85 is approved in a reply email,

Once the system server 50 receives the approval, the policy 85 is storedin the policy database 60 and is able to be accessed by the users of thesystem 200 as required.

Examples of some specific security policies 85 that can be implementedin system 200 include:

Report back This policy prevents a secure connection being establisheduntil the web server 70 is informed of the configuration of clientcomputer 20.

Don't allow other TCP/IP Connections. This policy prevents anyconcurrent internet connections not belonging to the web serviceprovider 80 and therefore restricts the submission of any information toany other servers once the activity is taking place. This policy isdirected at preventing any phishing attempts using bogus versions of thesite.

Limit browser windows to x. This policy limits the number of openintern& browser windows to the preconfigured number. This policy isdirected at preventing any pop-up windows or other unnecessary windowsthat might possibly be malicious.

Require up-to-date antivirus scanner This policy only allows the clientcomputer 20 to proceed in the secure lockdown mode, if an up-to-dateantivirus scanner is found on the client computer 20.

Only allow the following process groups This policy follows a ‘whitelist’ approach to limit the processes running on the client computer 20to those pre-approved on the program database 62, in order to minimisethe chances of a malicious process running on the client computer 20. Itwill be appreciated that such an approach is directed at stopping anyspyware/malware or other unwanted applications 90 (eg instant messagingapplications) from running during the online activity. Preferably, thispolicy will simply initiate the lock down process which will then makereference to program database 62 to determine which process groups areallowed.

Disallow the following process program groups This policy follows a‘blacklist’ approach and checks for running processes or programs 90which are known to cause problems or to compromise internet security. Ifsuch programs 90 are found on the client computer 20, they areterminated before online activity is allowed. Preferably, this policywill simply initiate the lock down process which will then makereference to program database 62 to determine which process groups arenot allowed.

It will be appreciated that numerous other security policies to regulatevarious aspects of the relevant computer systems, network connections,activities undertaken or any other suitable aspect of the session may begenerated and implemented, and are encompassed within the concept of asecurity policy. It will also be appreciated that a web service provider80 can change their security policy 85 settings at anytime, and the newsettings are applied to all the system 200 users when they connect to aweb server owned by the web service provider 80. Furthermore, the webservice provider 80 may either apply common security policies across allweb servers under its control or different security policies todifferent or specific web servers.

In alternate embodiments, the transmission of the security policies 85to client application 10 may occur during a handshake type scenariodynamically with the web server 70, or by using an already deployeddatabase from a trusted third party.

Policy Enforcement

The policy enforcer aspect of the client application 10 will enforce thesecurity policies 85 on client computer 20. In order to further securecommunications with the web server 70, the client application 10 mayturn the result of the security policy 85 examination process intoaction. The client application 10 accepts the security policy 85 list asinput and cycles through all security policies 85 that arenon-compliant, and either allow or deny a specific process, applicationor connection, which may include a warning before acting.

Each security policy 85 can have different policy enforcement statusessuch as warn, allow, deny. The client application 10 cycles through thelist of security policies 85 gathered from the policy database 60 andfor all security policies 85 that the client computer 20 does not complyto, takes the appropriate action. For example, all non-compliantattributes with the policy enforcement status of warn are allowed by theclient application 10 but the user 40 is required to accept andacknowledge that the client computer 20 does not comply. The allow anddeny enforcement statuses either allow or deny the communication ifnon-compliant attributes are found by the client application 10. It willbe appreciated that all the policy enforcement statuses can be used inconjunction, for example, warn and deny and that furthermore, the policyenforcement types are an extensible list and not limited to the specificenforcement types stated above.

The evaluation of how and whether the client computer 20 complies with aparticular security policy may be in the form of binary yes/noattributes, but are not limited in this manner and could also involve apercentage threshold, for example. Preferably, this evaluation iscommunicated to the web server 70.

Community Database

In the situation where web server 70 does not belong to a web serviceprovider 80 who is a subscriber to the system 200, a determination as towhether the web server 70 should be accessible by users needs to made.In order to do this, the client application 10 refers to the communitydatabase 61 as described above under the heading Identification. Furtheraspects of the community database 61 are now described.

The information in the community database 61 is updated by users of thesystem 200 and therefore provides a continually updated resourcecontaining all the information the client application 10 needs toevaluate whether a particular site, certificate, application or processshould be trusted by users of the system 200. In some cases, thisinformation may be automatically updated to the community database 61 byeach user's client application 10 on a periodic basis or at some othersuitable time.

Examples of the type of information available in the community database61 include:

Known Since This field tells the user 40 whether the web fingerprint 100of the web server 70 has a longstanding history or not.

Verified by the System This field indicates whether the relevant URL ispart of a black list from a third-party vendor like Netcraft orMicrosoft.

Pharming Check This check verifies whether the IP address beingconnected to actually belongs to the organisation that has registeredthe domain.

Average User Rating This field provides a score from 1 to 5 stars with a“subjective” classification from an author.

User Reviews includes user reviews of the web server 70 or web serviceprovider 80 where any user can write a review, but a valid email addressis required. The reviews may also be moderated by administrators of thesystem 200.

How did Other System Users Decide This field indicates the actions otherusers of the system 200 have taken in respect of this particular webserver 70 or web service provider 80.

It will be appreciated that this user community based approach of thesystem 200 will provide inexperienced users of the system 200 with ameans to leverage the knowledge of a large internet community and takethis into consideration before deciding whether the user 40 shouldtrust, for example, the web server 70 or not.

In one embodiment, the system 200 includes a feature called “communityautotrust” where the client application 10 automatically enables ordisables access to web servers that are verified in the communitydatabase 61. The autotrust feature may take any of the followingattributes into account in reaching a determination:

Known since

Verified by

Actions of the other system users

For example, the web server 70 is automatically trusted by clientapplication 10 if the associated web fingerprint 100 is known for morethan 3 days in the user community, is verified by a third party (bymeans of a white list) and/or at least 90% of the other system 200 usershave already trusted the site hosted by the web server 70.

On the other hand, an example of a web server 70 that wouldautomatically be blocked is with a web server with a web fingerprint 100which is known for less than 3 days or appears on a third partyblacklist.

It will be appreciated that other criteria or different values for thecriteria discussed above or any combination thereof, can be applied inthe determination of whether or not a particular web server 70 or webservice provider 80 is to be trusted.

In the situation where a user 40 has accessed their online banksuccessfully before and now the client application 10 calculates adifferent web fingerprint 100, the client application 10 will check theweb fingerprint 100 with the community database 61 and based on theknowledge of the community, will automatically block the connection tothe web server 70 in circumstances where this is an already knownattack, or if the web fingerprint 130 is known less than 3 days. Theuser 40 may in some circumstances be able to override thisdetermination.

Handshake between Client Application and Server

As shown in FIG. 3 and FIG. 4, the client application 10 submits anevaluation of whether the client computer 20 adheres to the relevantsecurity policies 85 of the web server 70 using an encrypted HTTPS postrequest. The evaluation is sent to the web server 70 so that the webserver 70 can determine whether the communication should proceed,whether certain restriction on the communications or the activitiesbeing conducted need to be applied, or whether the client computer 20needs to be configured in a manner complying with the security policies85 of web server 70, such as, for example the initiation of lockdownmode.

Some examples of information that may be transmitted during this postrequest include the unique identifier of the client computer 20 alongwith details of whether or not:

the client antivirus engine is active

the client anti spyware engine is active

possibly malicious software/processes have been detected

known malicious software/processes 90 have been detected

these detections have been overridden by user 40

secure lockdown of the client computer 20 has been activated

the user 40 is able to override the security policies 85

The above values are appended to a HTTP post request which is includedinto the HTML code.

Quiet Mode

In one embodiment, a quiet mode is provided which allows the clientapplication 10 to perform all the actions discussed above without anyinteraction from the user 40. Consequently, no pop-ups or any other userinteractions dialogs are displayed when a particular security policy isenabled. It will be appreciated that in such a situation, the webservice provider 80 will receive the status of the client computer 20during the handshake process and from the user's 40 perspective, thenotifications can be completely integrated into the online applicationor activity process.

Deployment

The client application 10 is an executable that can be deployed ineither a self running executable mode which does not requireinstallation on the client computer 20, or as a full installation inwhich the client application 10 is installed on the client computer 20and automatically analyses all outgoing Internet transmissions.

The foregoing discussion is considered as illustrative only of theprinciples of the invention. Furthermore, since numerous modificationsand changes will readily occur to those skilled in the art, it is notdesired to limit the invention to the exact construction and operationshown and described, and accordingly, all suitable modifications andequivalents may be resorted to, falling within the scope of theinvention.

1. A method of establishing secure communications between a firstcomputer and a second computer, comprising: communicating to the firstcomputer at least one security policy relating to the second computer;initiating an examination process on the first computer in order toevaluate whether the first computer complies with the security policy;the first computer communicating the results of the examination processto the second computer; and the second computer determining at least oneaspect of the secure communications between the first computer and thesecond computer; wherein the determination of at least one aspect of thesecure communications between the first computer and second computer isbased at least in part on the results of the examination process. 2.-35.(canceled)